-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rustdoc: add new CLI flag to load static files from a different location #57011
Conversation
IIRC when we first tried implement this feature, we had a problem on theme switcher. Javascript portion of the code was trying to load dark.css instead of dark-{suffix}.css. But I guess that is been fixed with I'd like to test this more thoroughly and make sure everything is getting cached properly. I'll report the result. |
Oh, you know what, i think the theme switcher may still be broken - i think the JS dynamically creates those paths, so i'll need to give it that separately. |
This is working great and achieving exactly what I was doing with my custom rustc used on docs.rs. 👍 |
Then here we go. Thanks @QuietMisdreavus! @bors: r+ |
📌 Commit 8dc8d7a has been approved by |
…=GuillaumeGomez rustdoc: add new CLI flag to load static files from a different location This PR adds a new CLI flag to rustdoc, `--static-root-path`, which controls how rustdoc links pages to the CSS/JS/font static files bundled with the output. By default, these files are linked with a series of `../` which is calculated per-page to link it to the documentation root - i.e. a relative link to the directory given by `-o`. This is causing problems for docs.rs, because even though docs.rs has saved one copy of these files and is dispatching them dynamically, browsers have no way of knowing that these are the same files and can cache them. This can allow it to link these files as, for example, `/rustdoc.css` instead of `../../rustdoc.css`, creating a single location that the files are loaded from. I made sure to only change links for the *static* files, those that don't change between crates. Files like the search index, aliases, the source files listing, etc, are still linked with relative links. r? @GuillaumeGomez cc @onur
…=GuillaumeGomez rustdoc: add new CLI flag to load static files from a different location This PR adds a new CLI flag to rustdoc, `--static-root-path`, which controls how rustdoc links pages to the CSS/JS/font static files bundled with the output. By default, these files are linked with a series of `../` which is calculated per-page to link it to the documentation root - i.e. a relative link to the directory given by `-o`. This is causing problems for docs.rs, because even though docs.rs has saved one copy of these files and is dispatching them dynamically, browsers have no way of knowing that these are the same files and can cache them. This can allow it to link these files as, for example, `/rustdoc.css` instead of `../../rustdoc.css`, creating a single location that the files are loaded from. I made sure to only change links for the *static* files, those that don't change between crates. Files like the search index, aliases, the source files listing, etc, are still linked with relative links. r? @GuillaumeGomez cc @onur
Rollup of 25 pull requests Successful merges: - #56802 (Add DoubleEndedIterator::nth_back) - #56909 (static eval: Do not ICE on layout size overflow) - #56914 (Ignore ui/target-feature-gate on sparc, sparc64, powerpc, powerpc64 and powerpc64le) - #56919 (Remove a wrong multiplier on relocation offset computation) - #56933 (Add --progress to git submodule commands in x.py) - #56936 (rename div_euc -> div_euclid, and mod_euc -> rem_euclid) - #56941 (deny intra-doc link resolution failures in libstd) - #56945 (Fix rustdoc-js tests) - #56967 (Replace current crate's searchIndex when regenerating) - #56970 (Mem uninit doc ptr drop) - #56973 (make basic CTFE tracing available on release builds) - #56979 (Adding unwinding support for x86_64_fortanix_unknown_sgx target.) - #56981 (miri: allocation is infallible) - #56984 (A few tweaks to dropck_outlives) - #56989 (Fix compiletest `trim` deprecation warnings) - #56992 (suggest similar lint names for unknown lints) - #57002 (Stabilize Vec(Deque)::resize_with) - #57011 (rustdoc: add new CLI flag to load static files from a different location) - #57027 (Optimize away a move) - #57034 (Inline tweaks) - #57039 (Update migrate warning wording.) - #57040 (Fix feature gate to point to 1.32.0 for `path_from_str`) - #57049 (Stabilize #[repr(packed(N))]) - #57050 (Fixed typo in HashMap documentation) - #57052 (Fix stabilization version numbers (exhaustive_integer_patterns + macro_literal_matcher))
This PR adds a new CLI flag to rustdoc,
--static-root-path
, which controls how rustdoc links pages to the CSS/JS/font static files bundled with the output. By default, these files are linked with a series of../
which is calculated per-page to link it to the documentation root - i.e. a relative link to the directory given by-o
. This is causing problems for docs.rs, because even though docs.rs has saved one copy of these files and is dispatching them dynamically, browsers have no way of knowing that these are the same files and can cache them. This can allow it to link these files as, for example,/rustdoc.css
instead of../../rustdoc.css
, creating a single location that the files are loaded from.I made sure to only change links for the static files, those that don't change between crates. Files like the search index, aliases, the source files listing, etc, are still linked with relative links.
r? @GuillaumeGomez
cc @onur